home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98a.txt / 000090_icon-group-sender _Wed Mar 4 12:22:06 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  3KB
  1. Return-Path: <icon-group-sender>
  2. Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
  3.     by baskerville.CS.Arizona.EDU (8.8.7/8.8.7) with SMTP id MAA23043
  4.     for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Wed, 4 Mar 1998 12:22:05 -0700 (MST)
  5. Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
  6.     id AA06262; Wed, 4 Mar 1998 12:22:05 -0700
  7. Date: Wed, 4 Mar 1998 09:41:45 -0700
  8. From: swampler@noao.edu (Steve Wampler)
  9. Subject: Re: Icon translation
  10. To: icon-group@optima.CS.Arizona.EDU
  11. Message-Id: <swampler-9802041641.AA00091256@orpheus.gemini.edu>
  12. In-Reply-To: <s4fd27c1.030@housmtp.oceaneering.com>
  13. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  14. Status: RO
  15. Content-Length: 2245
  16.  
  17.  
  18.  
  19. Charles Hethcoat wrote:
  20. > 
  21. > The only real way to speed up Icon is to build a custom computer
  22. > architecture specifically to execute the Icon-generated abstract code. 
  23.  
  24. Actually, I suspect there are ways to get rather substantial performance
  25. gains from Icon with an 'optimizing' compiler.  However, the type of
  26. optimization I'm thinking of is very difficult.  If I were independently
  27. wealthy, I'd pursue it, but I'm not.  Plus, Icon is already 'fast enough' for
  28. most of my needs.
  29.  
  30. If you carefully profile Icon programs, you may notice that there's a
  31. 'base cost' spread throughout the entire system.  This is what makes
  32. it look as though Icon can't be sped up much -  a rather high, flat
  33. cost foundation.  I believe that a significant fraction of this base
  34. cost is due to the use of descriptors in the implementation.  (Don't
  35. misunderstand me, I'm not knocking descriptors - they are a *major*
  36. factor in the flexibility and power of a language like Icon.)
  37.  
  38. If you look at 'most' Icon programs, though, a human can determine that
  39. much of the transfer of data in the program can be identified and typed.
  40. This is one of the important features of Ken Walker's Icon-to-C optimizer,
  41. removing unneeded type checks.  What that optimizer stops short of
  42. doing is removing the unneeded descriptors themselves.
  43.  
  44. If you know the type, there is very little need left for a descriptor, only
  45. strings [unless something has changed...] use the descriptor for anything
  46. else than a [type,value] pair.  Since descriptors are twice the size of
  47. values in Icon, and twice the native machine word size on most (all?)
  48. implementations, programs spend twice as much time pushing
  49. descriptors around as they would raw values.  Not to mention all the
  50. redundant type checks in the runtime system (in most circumstances)
  51. and the pulling apart and putting together of the descriptors.
  52.  
  53. An *amazingly good* optimizer should be able to strip descriptors from
  54. most places (not all) in an Icon program.  With appropriate support
  55. from the runtime system, speeds very close to C should be possible from
  56. an Icon compiler.
  57.  
  58. --
  59. Steve Wampler - swampler@gemini.edu [Gemini 8m Telescopes Project (under AURA)]
  60. The gods that smiled at your birth are now laughing openly. (Fortune Cookie)
  61.